COMMENT ⊗   VALID 00004 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	See also PLAN.RND for recent stuff from  RAND wrt the Planner project
C00003 00003	∂20-Mar-81  1558	GREINER at RAND-AI 	Things to do   
C00007 00004	∂Mailed to %RAND-AI KLAHR, DAVE 12:07 25-Mar
C00015 ENDMK
C⊗;
See also PLAN.RND for recent stuff from  RAND wrt the Planner project
∂20-Mar-81  1558	GREINER at RAND-AI 	Things to do   

* 0) Mail off finances to Hiltrud
* 1) Send to %RAND-AI KLAHR, DAVE:
	RLL-1 manuals, MRS manuals and CORLL stuff
	Point out to them, also, changing RLL to relation based easier:
	Edit UA-GETPROP (and friends) - now discuss general non
	unary functions... these as easy
	(ie AnyUnitFunction subset of AnyUnitRelation, and ...)
  Even easier - just change UA-GETPROP & UA-PUTPROP, but that's cheating.
	Inheritance: from father - defn of LastName =
	(Composition LastName Father) - note problem is am own grandpa
  Another use of inheritance - creating a new unit.  
	I've build various mechanisms for this.
* 2) FTP files from SCORE to RAND-AI - editing several of them
	[BACKUPDIR now just my own, LISP source code files changed to
	correspond to <GREINER> if at RAND-AI, ...
* 3) Ask GORLIN if there are any (known) incompatibilites between RAND-AI
	and SCORE.
	What about Small Lisps - are there any around?
* 4) Ask RICK for more space. (at least another 1K needed; but I can expand 
	make-good-use-of any arbitrary amount.
	I did all the assignments suggested.  Enjoyed the visit.
* 5) Tell Doug my the primary source for the files will henceforth be RAND-AI.
	(IE stuff elsewhere (on SCORE) just backup.  I'll be able to return
	<CSD.LENAT> to you.)

### Real Work ###
KLUDGE simulation
(i) Get new specs to work - ala Units.
(ii) Describe class of phrases - as sequence of words.
	Currently just generalizations of individual words considered...
	later subsets of words.
(iii) Use other pointers (besides this "generalization"): 
	Rationalization, ...
(iv) Make creating new slots cheaper - as we'll need one for each noun,
	it seems.  Twiddle with single function for creation,
	one which "conses" together the relevant ToInitialize slots.
	(Note - this function, of course, invalidated when PossibleSlots...
	is changed.  In fact, this should be used in leiu of it.  Especially
	when compiled... Have it NOT include those which are "NoOp"s.)

Actually, finish up current RLL stuff first - 
  *  when invalidating stuff
  *  GetValue macros.
-------
∂Mailed to %RAND-AI KLAHR, DAVE 12:07 25-Mar
Several comments
0) The memos describing RLL-1, CORLL and MRS are now en route.

1) Two final points on the theme of inheritance.
i) Here's how RLL would address (actually sidestep) the
"inheritance from parent" problem you mentioned:
To specify that one's LastName is just your father's,
simply give the unit associated with the LastName type of slot the
HighLevelDefn of
	(Composition LastName Father)
[A bit of notation: This is the same as
	LastName:HighLevelDefn = (Composition LastName Father)]
Now suppose you ask for U:LastName.
RLL first sees if any value is primitively stored there,
returning such a value if it is found.
Otherwise it finds the value which fills U's Father slot; call it F.
[If there is no such U:Father value, the GetValue function returns,
and indicates it cannot determine the LastName of U.]
Otherwise, RLL now recursively tries to find F:LastName.
[The only problem with this solution arises if ever someone is
his own Grandpa... But that should cause grief anyway.]

A similar mechanism could be used to indicate that one of each chromosone
comes from the Father, and the other part from the Mother; etc.
Notice how this explicitness makes the whole notion of inheritance
less confusing; indeed almost vacuous.

ii) The other main (closely related) use of inheritance comes when a new
unit is being initialized --
ie, determining the initial values for various slots based on the unit's
"ancestry".  I've build various mechanisms for this.
(One each for the Epsilon, Subset and TypicalExample relations.)

2) Changing RLL to be relation-based
Soon after I left I realized that changing RLL to be
relation-based would be yet even easier than I'd imagined.
I'd only have to edit the primitive storing and retrieval functions -
(eg UA-GETPROP, UA-PUTPROP and friends).

[Of course this is sorta cheating, as RLL does not yet have a handle on these
primitives.  Eventually RLL will actually store
properties about these low level functions;
and those properties would have to be updated.]

Anyway, once done RLL could then handle general non-unary functions.
By considering slots to be a (now proper) subset of the set of
relations involving units,
we could now begin considering other storage/retrieval schemes.
See Mike Genesereth's "Metaphors and Models" paper (in AAAI#1))
for comments on managing numerous representational structures.

The MRS system is better able to achieve this desired versatility.
RLL will eventually become a "plug in" module to this system; and thereby
acquire access to MRS's store of implementation-related facts (concerning
p-lists, bit vectors, relational DBs, etc).
With this information RLL would be able to undergo such modifications "honestly".

-----
(Based on hopeless optimism if not facts,)
I hope these points have served to help, rather than hinder,
this presentation of the concept of an rll.
Let me know if there is anything else I can attempt to clarify.

3) RLL Bulletin Board
Phil is currently on the mailing list for this BB (which, who knows,
may one day say something.)
Should I add your name there as well, Dave?

Russ